The Controller Area Network (“CAN”) communications protocol has been known for 25 years (referred to herein as “Classical CAN” or “CAN-C”). The CAN-C protocol is used for communication among several communication modules or micro-controller units (“MCUs”) on a common bus. In 2012, a new communication protocol based on CAN was proposed having up to 64 byte where data can be sent with a higher bit-rate as compared to CAN-C. This new CAN-protocol was named CAN-Flexible Datarate (“CAN-FD”). A CAN-FD controller can handle both CAN-FD frames and CAN-C frames concurrently on the same CAN-bus. The problem is that previous produced CAN-controllers cannot handle the CAN-FD format. If a CAN-C controller receives a CAN-FD protocol message, the CAN-C controller generally will output an unrecoverable Error-condition.
This compatibility problem is significant because there are several hundred different products with using CAN-C made pursuant to the previous version of the International Standards Organization (“ISO”) 11898-1. Interest in adopting CAN-FD as a higher speed protocol is discouraged because such modules cannot be used on a bus having a module that can only communicate using CAN-C.
Although theoretically one can convert an ECU (Electronic Control Unit) such as the one illustrated in FIG. 2 from Classical-CAN to CAN-FD by replacing the integrated Classical CAN-controller with a CAN-controller with CAN-FD functionality, but such a conversion involves an investment and time. First, it is necessary to design a new MCU where the Classical-CAN controller is replaced by the CAN-FD controller. Then it is necessary to make new masks defining how such device will be produced. After the device is produced will it be necessary to verify and validate that everything is working as expected. This process will take at least six months before there are any new devices to test in the ECU. When you have the ECU with the new MCU including the CAN-FD controller, it will be necessary to do some changes in the software to support the CAN-FD controller. Even if those changes are relatively small, it will be necessary to evaluate that nothing else changed. If the devices have a safety related task, it will be necessary to retest the complete unit. Such test will take several months up to a year assuming that the first MCU samples have no bugs. In most cases will there be some parts that did not come out 100% correct, and it will be necessary to make a redesign of the MCU.
One attempt to solve this problem includes inserting a filter between CAN-FD portions of the bus and any CAN-C modules that intercept CAN-FD communications before they reach CAN-C modules. This solution, however, is not elegant because a CAN-FD communication can only be identified by reading a particular bit (FDF bit) of the communication, which according to the CAN-C and CAN-FD protocols is several bits into the message. In CAN-C the FDF bit is always logic zero and in CAN-FD the CAN-FD bit is logic one. Thus, this approach will result in either generation of an error message when the CAN-C controller sees that the message it was receiving is cut off by the filter or a delay where the filter holds the message until receipt of the FDF bit. In the second situation, however, holding back the message can interfere with communications arbitrations that coordinate how the modules communicate amongst themselves.
In the first situation, it could be possible to prevent this Error-frame from coming out on the CAN-bus, but it will still cause confusion for diagnostics to distinguish those artificial local Error-Frames from real Errors. If there are too many CAN-FD frames on the bus, there is a risk that those Classical-CAN units will go Error-passive, which will change the behavior of those modules in the system.
Even if one were to accept that each CAN-FD frame will result in a local Error Frame, there remains an even bigger problem. The CAN protocol is designed to make it possible to start sending the next CAN frame directly after the previous frame has ended. This makes the CAN-protocol effective, but this also demands that all CAN devices must complete their CAN-frames simultaneously, including the Error Frames, to begin the next CAN frame in the next succeeding bit on the bus. The probability that the local Error-frame will end at the same instance in time as the CAN-FD frame on the CAN-bus is very low. If a second CAN-message will start directly after the Error-frame for the local node or after the CAN-FD frame on the bus, there will an unrecoverable condition with the only solution being to place an Error-frame at the same time both locally and on the CAN-bus. This will force all units to restart the communication with a great probability that the same problem will occur a second time until some units will go bus-off and leave the communication.